Subject: Re: Preliminary SIG agenda: Names in ACTLU/ACTPU

From: David Bryant/HQ/3Com <[email-masked]>
Date: 24 Oct 96 9:59:12 EDT

Brian is correct.

The real issue here has nothing to do with DLUR as VTAM already provides the PU 
name on 
ACTPU for DLUR nodes.   The real issue was that many 'non-sna' devices: Frads, 
DLSw, even bridges
could benefit from the inclusion of names in ACTLU and ACTPU.   The idea was 
that these types of 
devices could use the names to correlate DLC type information (LLC link 
up/down) with SNA pu/lu names.

It's really all about making SNA network management better in networks that are 
not 100% SNA.

-Dave
PS. Sounds like the VTAM proposal will hit the mark.

To: aiw-appn-reference-redist  @ nsd.3com.com @ UGATE
cc:  
From: bjewell @ 3mail.3com.com (Brian Jewell) @ UGATE    
Date: Thursday  October 24, 1996 11:27 AM
Subject: Re: Preliminary SIG agenda
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ralph,

Re: the Agenda...

> 
> MAPPING LU AND PU NAMES BETWEEN VTAM AND TYPE 2.0 NODES
> 
> There is a proposal to add a new system definition parameter to VTAM to allow
> LU and PU names to be sent to DLUR-attached devices.
> 
> 

This issue was first raised a while ago and I've forgotten some of the
specifics about what was proposed. But I do think the scope of it went
beyond just dealing with the problem for DLURs. The original intent was
to provide a means for passing PU/LU names in traditional SNA networks,
as well.

Do other members share this opinion?

-Thanks

Brian Jewell
3Com, Inc.

> 
> Here's the list I have so far of architecture items to be
> discussed at the upcoming AIW meeting.  As always, we can
> add others if needed, just let me know what you think is
> needed.
> 
> I look forward to seeing you in Raleigh.
> 
> 
> CURRENT APPN ARCHITECTURE ITEMS
> _______________________________
> 
> 
> YEAR 2000 COMPLIANCE
> 
> We will discuss SNA Formats hits and product implications of two-digit
> representations of years.  Changes to the interpretation of some fields are
> proposed.
> 
> 
> CORRECT DLUR REQDISCONT PROCESSING
> 
> When a DLUR currently receives a REQDISCONT request from a downstream PU
> (DSPU), it converts the request into a REQDACTPU request and sends it to the
> DLUS.  In addition, upon receipt of RSP(REQDACTPU) from the DLUS, DLUR
> converts the REQDISCONT request into a positive RSP(REQDISCONT) and forwards
> it to the dependent PU.
> 
> The proposal is documented in "abs8407.txt" and "arch8407d.psbin".  Approval
> of this item is requested at the meeting.
> 
> 
> INCLUDE ROUTE SELECTION (X'2B') CV ON +RSP(BIND) RU
> 
> DLUR architecture for reextending a +RSP(BIND) should be updated to reinsert
> into the +RSP(BIND) a CV X'2B' if one was received on the BIND request.
> 
> The proposal is documented in "abs8418.txt" and "arch8418d.psbin".  Approval
> of this item is requested at the meeting.
> 
> 
> AUTO-ACTIVATION ENHANCEMENTS
> 
> This item updates CS architecture to more accurately reflect product
> implementations of auto-activatable links.  Products do not bring up such
> links and exchange XIDs in order to negotiate TG number and to get the link
> into topology.  Instead, the links are inserted into topology based on
> configured information.
> 
> Approval of this item is requested at the meeting.
> 
> 
> QUIESCING CONNECTION NETWORK TGS
> 
> HPR Extensions for ATM Networks states that connection network TGs should be
> marked as quiescing rather than nonoperational when the port's link
> activation limit is reached or the port's upper reserved bandwidth threshold
> is exceeded.  The base CS architecture needs to be changed so that the same
> action is taken for connection network TGs for other link technologies.
> 
> Approval of this item is requested at the meeting.
> 
> 
> LAN SIGNALLING INFORMATION IN RSCVS
> 
> This is a new proposal to minimize the number of bytes in an RSCV that
> includes a connection network by eliminating unused signalling information.
> 
> This is a new proposal.
> 
> 
> MAPPING LU AND PU NAMES BETWEEN VTAM AND TYPE 2.0 NODES
> 
> There is a proposal to add a new system definition parameter to VTAM to allow
> LU and PU names to be sent to DLUR-attached devices.
> 
> 
> UPDATES TO TOPOLOGY AWARENESS OF CP-CP SESSIONS
> 
> Due to some confusion about the interpretation of the 'CP-CP Session support
> and status' field in the TG Characteristics (X'47') Control Vector, a
> clarification has been made to the formats.  The file, "arch8419.psbin"
> contains these changes.
> 
> This is a clarification.
> 
> 
> Ralph Case                    [email-masked]    (919)254-1882
> AIW APPN Reference SIG Chair
> IBM Networking
>